烂完了，还没修，是想等着哪天上新闻吗？

有什么开源/公益项目缺钱或者缺机器的？

要喝免费旺仔牛奶的，私。

已送。

再次推荐。


uv tool install sshconfig_to_ananta[toml]
uv tool install ananta[speed]

最后还是感觉不对劲，为什么我们要传这么多数据，仔细一看发现全是垃圾，马力全开的话要不了几天数据库就会被塞满垃圾。于是项目停了，打回炉重造。

然后本月则是另一个项目，还是性能问题，跑几十分钟软件就卡住发不出任何请求了。这个倒是简单，开 pprof 等几十分钟后看一下 goroutines，发现全挂在了一个地方，是没有给 tcp dial 设超时。设个超时就修好了。
然后开开心心继续跑，结果又发现 net/http.(*persistConn).writeLoop 和 net/http.(*persistConn).readLoop 一直在缓慢增长并且超过了我们实际正在使用的连接数量。这个太经典了，不就是连接漏了嘛。但是找了一圈也没找到漏的地方，因为泄漏速度非常缓慢，大概百万份连接才泄漏几份？而且创建连接的 goroutine 按照设计，创建之后就早早 return 消失不管连接了，也不知道这些孤儿连接是谁创的。但幸好可以传入 ctx 来直接 cancel 整个请求/连接，所以这个问题也解决了。
推到生产，发现能跑了，性能可以接受，但是无论怎么 scale up scale down，速率只能跑到 5Gbps。

这时候又发现我们的 TCP gateway 上的 tailscaled 发疯了，明明 tailnet 根本没有任何流量，但它却始终在吃单核 100% cpu （流量跑到 4Gbps 时），而且是吃的 kernel 的 cpu 时间，我把流量停掉，它就不吃了，开启，它又开始了。虽然貌似对我们业务没影响，但好不爽啊。我一开始怀疑可能是 tailscale 的 tun 跟 iptables/conntrack 可能过滤&追踪包有些 overhead，即使包不是发给 tailscale 的？。但是关了 tailscale 的包过滤和改iptables，都没效果。然后一跑 perf，好家伙，tailscale 的 Services List (Port List) 功能每秒会读一次 /proc/net/tcp、/proc/net/tcp6、/proc/net/udp、/proc/net/udp6。我们的连接太多了，kernel 甚至无法在一秒内返回这些 /proc/net/* 。还好 tailscale 这个功能可以关掉，关掉就好了。
参考：https://github.com/tailscale/tailscale/issues/10430

然后还是卡在 4Gbps 过不去。各种 profile + trace + 乱猜 + 改配置 + 换网卡，鼓捣了一周，今天我们最终终于找到了原因……昨天其实我就非常接近原因，但是我很怀疑啊，感觉不可能，同事之前说那块性能非常非常棒所以几乎不可能出问题的。
今天同事对那块加了 32 台杜甫来处理……非常完美啊，终于达到 10Gbps 了。

才高兴了一小时，我们又注意到请求成功率大幅下降，甚至跌破了之前的 4Gbps 时的成功率。不过这时候的问题已经与技术无关了……

我嘞个 JDBC 啊，先进。

如何检验别人的 Go 代码是否是 vibe 的。
ctrl+s，看 import 的顺序有没有变化。

哇塞，哭了啊，完全是给房东打工。税后工资，房东一半我一半，不多不少刚刚好。😭

终于关了存储桶的访问。工商银行“太厉害”了。

xLog 的各种 API、以及链上的 RPC、以及数据导出网站 export.crossbell.io 都已经废了。

刚糊了个 xLog 博文导出工具 https://xlog-takeout.saveweb.org/ 出来。
整个 xLog 的博文去掉大部分 spam 后也才 34k，很小。懒得写后端，直接前端加载 300MiB 的全量 sqlite (gzip 后 100MiB)。

xlog 受害者们尽快导出吧（IPFS 上的图片附件已经没了大半了）。

练功中，勿扰。。。

今天终于找到了根本原因：